home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0021.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  5.2 KB  |  127 lines
  1. Someone mentioned that WAIS should obviate the need for FTP. I disagree.
  2. I think that the WAIS protocol is good for finding documents, but not
  3. necesarily for transferring or displaying them.
  4.  
  5. There are two scenarios that WAIS is good for:
  6.  
  7. A. The database is built for wais. For example, DowQuest. That database is
  8. stored so that it can be efficiently acessed and delivered through WAIS.
  9.  
  10. In this case, it makes sense to transfer the contents of the documents through
  11. WAIS and to use the nifty chunking ideas.
  12.  
  13. B. The database is built for system X, and somebody sicked waisindex on it.
  14. This is currently, by far the most common case. Look at all the USENET
  15. archives, biology databases, library catalogs, etc. that weren't designed for
  16. use with WAIS, but they work pretty well.
  17.  
  18. In this case, it makes more sense to me to transfer and/or present the
  19. documents using the clients that the database was designed for. The WAIS server
  20. should send enough information to retrieve and/or display the document using the
  21. other client.
  22.  
  23. Example: the archie database. As a user, I want to query the archie
  24. database using WAIS's fulltext and relevance feedback queries, but I want to
  25. retrieve the documents with FTP, and I may want to "present" them with
  26. uncompress and tar, or lpr, or ghostscript, etc.
  27.  
  28. Example: USENET news. I want to query using WAIS, but read it with my
  29. news reader.
  30.  
  31. Example: my mail box. Query with wais, display with Xmh, Elm, mh, emacs, etc.
  32.  
  33. Retrieving the whole document with WAIS and saving it to a file is no good in
  34. this day and age of client-server computing. The WAIS client may be on a
  35. machine with no disk space to spare. And I may want to use the file on a
  36. different host.
  37.  
  38. So we see that the WAIS client needs to hand off documents to other clients.
  39. This raises the question: what information should the WAIS search client pass
  40. to the retrieval/display slave clients, and how?
  41.  
  42. The CNI-ARCH folks are discussing a standard for document identifiers. I
  43. think this is definitely one of the things that WAIS should pass, but it's
  44. not the only thing.
  45.  
  46. I'm beginning to look at documents sort of like records in a relational
  47. database. The WAIS client should negociate with the slave client what fields
  48. they have or are interested in. An obvious representation for these records
  49. is the RFC-822 mail message format.
  50.  
  51. Example: the archie database.
  52.  
  53. I use my xwais client to query archie.src on "vgrind." My xwais client gets a
  54. list of docids from the WAIS server. These docids contain at least the score
  55. and the CNI-ARCH style docid, which in this case would be enough info to
  56. construct a prospero file handle [I'm not sure there is such a thing as a
  57. prospero file handle, but play along anyway...].
  58.  
  59. I play gui-games with xwais until I get the list of documents that I like.
  60. Then, using some mechanism like the X selection mechanism or drag-and-drop
  61. (combined with SMTP, perhaps), I select a document and give it to my xftp
  62. application. The xwais client and the xftp client agreed earlier that they
  63. would send messages like:
  64.  
  65. From:        xwais@x.server.host
  66. To:        xftp@x.server.host
  67. CNI-ARCH-ID:    <12345@prospero:quiche.cs.mcgill.ca>
  68. SIZE-IN-BYTES:    120034
  69. FTP-HOST:    export.lcs.mit.edu
  70. FTP-USER:    anonymous
  71. FTP-CD:        pub/util
  72. FTP-GET:    vgrind.tar.Z
  73.  
  74. blah blah blah about vgrind, perhaps explaining what query found this file,
  75. or perhaps some stuff from the README in vgrind.tar.Z
  76. .
  77.  
  78. I have already played gui-games with xftp to tell it where to put the files
  79. it retrieves. When it gets this message, it does the HOST, USER, CD, and GET
  80. commands, and presto! I've got my document.
  81.  
  82. I think if we had a suite of these gui tools talking SMTP to each other, they
  83. could get a lot of work done. More examples:
  84.  
  85. To:    xtar@x.server.host
  86. fopen:    /home/connolly/vgrind.tar
  87.     or perhaps
  88. popen:    zcat /home/connolly/vgrind.tar.Z
  89.  
  90.     xtar has a gui for selecting a place to extract the archive
  91.  
  92. To:    xlpr@x.server.host
  93. fopen:    /home/connolly/vgrind-2.1/manual.ps
  94.     or
  95. popen:    zcat /home/connolly/vgrind-2.1/manul.ps.Z |
  96.  
  97.     xlpr selects destination printer, copies, etc.
  98.  
  99.  
  100. Most tools fit in naturally. The $PAGER and $EDITOR, and perhaps $SHELL tools
  101. could be MUCH more powerful if they could interoperate this way. [Has anybody
  102. used mx and tx from John Osterhout(sp?) ? Those and the Tk toolkit allow X
  103. applications to send commands back and forth.]
  104.  
  105. For example, the World-Wide-Web browser would fit the role of $PAGER in this
  106. environment. It would receive messages to display WWW nodes, containing their
  107. HTTP address (or NNTP, FTP, etc.). It would then display the node and allow
  108. the user to scroll around and choose anchors etc. It could handle most
  109. anchors by itself, but it might want to let the user select a region of text
  110. and send it to the WAIS client.
  111.  
  112. I don't think there's an $EDITOR that fits very well, though emacs is always a
  113. contender, and you have to have vi.
  114. [I think the mouse support in emacs needs a LOT of work, but I probably
  115. haven't seen the latest and greatest stuff.]
  116.  
  117. I'm not sure how $SHELL fits into all this but, for example, folks send shell
  118. commands in mail messages to each other all the time. You could just select
  119. the shell command in your mail $PAGER, and drag it to your $SHELL x-client
  120. for invocation.
  121.  
  122. I hope I get time to try to implement a couple of these ideas. Then we can
  123. all see whether they're worth persuing.
  124.  
  125. Dan
  126.  
  127.